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ETKT.D OF INVENTION 

The present invention relates to input and output functions of 
computer programs. More specifically, the present invention is 
related to enabling location independent and location tremsparent 
5 p interaction between a program and a user, one or both of which is 
mobile. 

si- 

y To support interaction between a user and a program, 

III 

H current systems require the program and the user to be constantly 
10 Q aware of each other's location. If a program, such as a mobile 

m 

agent program, moves to a different host, it must return to the 
user location or communicate through another program at the user 
location, to receive input or display output to the user. This is 
a problem when the user is mobile (e.g., using a laptop or handheld 

15 device) and, therefore, usually not in the original location from 
which the program was launched. Similarly, if a user chooses to 
move to another location on a network, that user must access the 
n»chine at which the program is executing in order to provide input 
or to receive output from the program. 

2^ In prior art systems, interactions between a program and 

a user are handled using standard input and output constructs. For 
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exanple, in C programiing language the input construct is the 
"scanfO" function and the output construct is the "printfO" 
function. In Java language, the input is performed using methods 
in classes such as " java.io.ZnputStreaaneader" and 
5 **java.io.InputStreaa,*' while output is perfomed using methods in 
classes such as "java.io.PrintWriter" and "java.io.PrintStream." 
For such programs, both the user and the program must be at the 
H same location. 

Q In conventional mobile agent systons, such as those 

10 pi described in U.S. Patent No. 5,603,031, issued February 11, 1997, 
,,1 entitled "System and Method for Distributed Coaqoutation Based Upon 
the ffovanent, Execution, and Interaction of Processes in a 
|{ Network," by White et al. and "IBM Aglets Workbench — Programming 
Mobile Agents in Java", Proceedings of 1997 World Wide Coa^mting 
15 g and Its ^plications, Japan, pp. 253-266 by Lange et al., the 
program executes part of its code at one host location, then moves 
to aiK>th«r host location where it executes a next portion of code, 
and so on. Interaction between a mobile agent and a user in sucdi 
a system is achieved by the agent living to and executing at the 
20 user's machine lAen display of data to the user and/or receipt of 
input frcxB the user is required. 

The conventional systems have three main limitations. 
First, both the program and the user have to be aware of each 
others' location at all times. Second, in situations «Aiere a 
25 program must move to the location of a user, the user's macdiine 
must have a program execution environment available to host and 
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execute the progreuD at any time. Third, while mechanisms exist to 
supply initialization parameters to a prograa before it begins 
execution, after the program has started execution, there are no 
nechanisms in these systems to permit a user to both determine the 
status of the program and to provide input to the program during 
program execution and/or before the program asks for them. 

An object of the present invention is to provide a system 
and TOthod for permitting inpit and outiatt betwe^ a user and a 
program without the requirement of each entity constantly 
maintaining knowledge of the other entity's location. 

Another object of the present invention is to provide a 
system and method for permitting input and output between a user 
and a program without requiring the user's machine to have ah 
execution environment available in %Aiich the program can run. 

Another object of the present invention is to provide for 
a user to both determine the status of a mobile program during 
execution and supply input to a program during execution and before 
input is actually needed. 

SPMHftBY OF THE IMVEMTIOW 

These and other objects of the inv^tion are realized lay 
the present invention comprising a system and method therein a 
mobile user, or a user interacting with a mobile program, can at 
any time initiate a program status request. iSie inrogram status 
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request initiates the sequence of events whereby the current 
location of the {nrograa is deterodned and/or the current user 
location is nade available to the program without the necessity of 
either entity changing location. Further, the ag^t script for the 
prograa maintains a c(»^site data structure «Aiich includes an 
input buffer for storing input variables, an output buffer for 
storing output values to be displayed to the user, a program state 
data structure, and an opticmal bag buffer for temporarily storiiMf 
input values whic^ the program will need in the course of future 
execution. By maintaining such a composite data structure, it is 
assured that all necessary information can be provided at a program 
location regardless of whether the program or the user has 
relocated. 



BRIEF DESCRIPTION OP THE TOAWTWG 

The present invoition will be understood by reference to 
the drawing, wherein: 

FIG. 1 shows a networked system into tdiich the present 
invention can be incorporated; 

FIG. 2 shows an example of an agent script with input and 
output statements; 

FIG. 3 shows an anbodiment of the relevant data 
structures of a mobile agent script according to an aspect of the 
present invention; 
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FIG. 4 Shows an embodiment of the logic of the present 
invention for handling inpfut and output by the Agent Execution 
Shell of the system of FIG. 1; 

FIG. 5 shows an embodiment of the logic of the present 
invention for processing a user's request for status; and 

PIGS. 6a, 6b, 6c and 6d show an example scenario in which 
a user launches the script from one geographic location and, while 
moving, continually monitors the program, views results of the 
program and supplies input values as needed. 

PCTAILED DESCRIPTION OP THE gRgmPie p EMBODTMRilT 

The following are definitions of some of the terms used 
in this specification: 

A host or host madiine is a coii^uting system, such as a 
mainframe, desktop personal con^uter, portable laptop computer or 
handheld device on irtiich a program is executing. 

A network is a set of hosts, interconnected by some 
physical and logical coBmunications infrastructure. 

A user is a human user of the network environment. 

A client is the user's interface to a network and may be 
a computer, handheld portable device, or other device having 
communication capabilities. 

A program is a sequence of instructions that execute on 
a host machine. 

A mobile program is a program, such as a mobile agent, 
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that moves from one host machine to another, executing some of its 
instructions at eac^ host machine. 

An Agent Server is a host machine having the executi<m 
environment for a mobile agent. 
5 An Agent Bxecution Shell (AES) is a software subsystem at 

a hcMst's Agent Server in which a mobile agent ^ecutes part of its 
instructions. 

1'^ ^e preferred embodiment is described in the context of 

CI a program that is mobile such as a mobile agent. 
10 p FIG. 1 depicts a system into which the feettures of the 

\| present invention can be incorporated « Here, a networked system 
100 connects computers that have distinct roles in the system. The 
comimters 102, 104a, 104b and 106, which c£tn be running 
fi conventional operating systems such as OS/2, UNIX, AIX or Windows 
15 y HT, are interconnected by way of a communication network 108 in 
conjunction with a communication protocol. The communication 
protocol can be, for example. Sun Microsystems RFC, which can run 
on ODP/IP or TCP/IP* The network 108 can be a LAN, Internet or 
intranet. The client 102 and Agent Servers I04a, 104b can be 
20 eittbodied by conventional personal computers (PCs) such as TBM PCs. 
On ea<^ computer, there is a conventional communication system 112, 
such as the TCP/IP stack in the operating system, that is used to 
communicate over the network 108. Alternatively, clients al&o can 
be embodied as handheld portable TObile devices, such as a 
25 PalmPilot or a smart cellular telephone. ISiese mobile devices can 
run proprietary operating systems using cellular telephone 
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technology, infrared conmunication means, or other equivalent 
neans, to connect to the cmaaDUUiication network 108. Note that the 
distinction between a client 102 and an Agent Server 104a, 104b nay 
be logical or physical and that the client need not be able to 
provide an executi<m environment for the relevant program. 

Although only one client is shown in PIG. 1, there can be 
many clients in the system 100. An agent program is launched from 
a client machine 102, using a subsystem called the Agent Personal 
Assistant (APA) lio. in addition to agent launch, this subsystem 
is capable of debugging, updating euid checking agent status, such 
a subsystem is disclosed in U.S. patent application Serial No. 
08/847,079 of Devarakonda et al, entitled, "Dynamic HObile Agents," 
filed May 1, 1997. In the present invention, it is preferable that 
the APA 110 be embodied as an application with a web interface. 
The APA 110 interacts with a Desktop Server 114, located within a 
Web Server 106, to perform these tasks. 

There can be a plurality of Agent Servers in the system 
100. Each of the Agent Servers l04a, 104b supports an execution 
environment that includes a software subsystem referred to as an 
Agent Execution Shell (AES) 120. mis AES 120 acts as the single 
coordinator for agent execution and maintains an internal table 
containing the state of all currently active agents. Each Agent 
Server additionaly maintains at least one routing table for 
recording the locati(»is(s) from and to ^irtiich mobile agents iK>ve. 

FIG. 2 shows a typical example of agent code to be used 
with the present invention. After p^forming some confutation on 
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a machine, the agent moves to the next host machine Q at step 200. 
The next host may be specified in the code or may be dynamically 
determined as discussed in the aforementioned patent application, 
the disclosure of which is hereby incorporated by reference. The 
agent code may contain the construct PRINT for providing output and 
the construct READ for reading input values from machine Q. As 
illustrated, at step 202a, the PRIIH? construct enables the agent to 
display results to a user, while the READ construct, at step 204a, 
enables the agent to request input from a user. After perfoming 
its computation as required, such as executing the READ, PRINT or 
other instruction, the agent moves to machine R at line 206. 
Again, the agent code may contain a PRINT construct and a READ 
construct, which may be executed at 204a and 204b, respectively. 
The code completes execution at step 208. 

FIG. 3 shows a composite data structure associated with 
an agent script 302 as it moves through the network 108 in 
accordcuice with the present invention. While the contents of the 
components of the c(»nposite data structure change as the agent 
script moves, the data structure components, including bag 304, 
STOOUT 306, STDIN 308, and program state 310 remain available. A 
"bag" 304 is a buffer that contains a set of variable name/value 
pairs which have been preset or input dynamically for future 
program usage. When the program requires input, the agent script 
examines the contents of the bag to locate values for variables and 
then retrieve the values. The value for a particular variable name 
could be a set of values that would be returned sequentially for 
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successive requests for the same name. If the bag does not contain 
a value for the needed variable, the agent script blocks and waits 
for the user to input the needed data. The bag buffer may be 
implemented as an array, hash table, tuple space, or other 
equivalent data structure. «STDOUT" buffer 306 contains all the 
output generated by an agent. The contents of the STDOUT buffer 
306 are displayed to the user when requested. "STDIN" buffer 308 
contains the variable names for which an agent script is awaiting 
input values from the user. The "STDIN" buffer 308 is used by the 
AES 120 to communicate values for input variables to the agent 
script. Finally, program, stack and variable data structures are 
Included for representing the program state 310 of the agent 
script . 

FIG. 4 shows the method steps performed by an embodiment 
of the AES 120 when executing program statements of the agent. 
Only statements relevant to the present invention are shown in FIG. 
4. In step 402, the AES 120 examines the next statement to 
execute. In step 404, the AES 120 determines if the statement is 
the END statement. If it is the END statement, the AES terminates 
execution of the agent at step 406. If the next statement is not 
the END statement, the AES 120 determines if the statement is a 
PRINT statement at step 408. If the next statement is a PRINT 
statement, the AES 120 retrieves values for the arguments to the 
PRINT statement from the program state 310 and appends the values 
to the STDOUT buffer 306 in a pre-determined fomat in step 410. 
A STDOUT buffer 306 is associated with each agent. The AES 120 
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then continues with the execution of the agent by returning to step 
402, 

If, In step 408, it Is concluded that the statement Is 
not a PRINT statement, the AES 120 next determines. In step 412, If 
5 the statement Is a READ statement. If, In step 412, It Is 
determined that the stat^ent Is a READ statement , then the AES 120 
checks whether the needed variable values are available In the bag 
304 In step 424. If the values are available, the values are 
retrieved and removed from the bag 304 In step 426. The variables 

lis.l 

10 M are updated, and the AES 120 continues execution of the program by 

mi 

H returning to step 402. If, In step 424, It Is determined that the 
M values are not available, the AES 120 appends the names of the 
arguments for the READ statement to the STDIN buff er 308 In step 
414. optionally, in step 416, the AES 120 then notifies the user 
15 via electronic means such as pager/beeper/electronic mail that 
'■""^ Input Is required. The preference to be notified can be specified 
by the user when the agent script is launched* 

In step 418, the AES 120 suspends execution of the 
program and waits for notification that the Input values are 
20 available. The logic for notifying the AES 120 about input values 
is shown in FIG. 5, described hereinbelow« After the AES 120 
receives notification in step 420, the AES 120 updates the program 
state 310 with new values in step 422, and continues with execution 
of the program by returning to step 402. The AES may additionally 
25 update the bag contents if the user has provided input which the 
user knows will be required by the program in succeeding steps* 
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If, in step 412, It Is determined that the statement is not a READ 
statement, the AES 120 processes other statements as appropriate, 
in step 422, and continues execution of the program by returning to 
step 402. In one optmized embodiment, the entire contents of the 
5 bag could be consumed at one time (assuming that the bag contains 
more than just the immediately-required input) and utilizes the 
consumed input as required without having to re-examine the bag 
l„i content at each input juncture of program execution. 
Q FIG. 5 shows the steps through which a user interacts 

10 with an agent in an embodiment of the present invention. A user 
j{ initiates a status request for an agent from the APA 110. The 
li request is forwarded by the APA 110 to the Desktop Sejcver 114 at 
O the Web Server. The Desktop Server 114 then forwards the xrequest 

U as a STATUS request to the AES 120 at the Agent Server where the 

ill 

15 rt agent was initially launched. The AES 120, in step 502, receives 
the STATUS request forwarded by the Desktop Server 114. The AES 
120 next retrieves the agent state from the internal state table, 
in step 504. The AES 120 then determines if the agent is still 
executing at the present location, in step 506. If the agent is no 

20 longer executing at the present location, the AES 120 checks its 
routing table and then, in step 508, forwards the STATUS request to 
the site where the agent was sent (and the method resumes with step 
502 at the next machine). 

If it is determined, in step 506, that the agent is 

25 currently executing at the present site, the AES 120 retrieves, in 
step 510, the STDOUT buffer 306 and the STDIN buffer 308, each 
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associated with the agent state. If the STDIN buffer is not empty, 
such that input is required, the AES additionally notes the current 
logical address of the agent. In step 512,' the AES 120 sends a 
message to the Desktop Server 142 containing the STDOUT and STDIN 
buffers 306, 308. If the STDIN buffer 308 is not empty, the AES 
120 also sends the current logical address of the agent in the 
message, so that user input can be properly routed. 

In step 514, the Desktop Server 114 receives a reply for 
the STATUS request. The Desktop Server 114 extracts the contents 
of the STDOUT and STDIN buffers from the message. In step 516, the 
Desktop Server 114 displays the contents of the STDOUT buffer to 
the user via the APA 110. If the STDIN buffer was not en^ty, the 
Desktop Server 114 also requests Input from the user, l^n receipt 
of user input, the Desktop Server 114 sends a message to the AES 
120 where the agent is currently located, at step 518. The AES 120 
receives the message, at step 520, notifies the agent of the new 
values, and updates the buffers as necessary. As described in FIG. 
4, the agent resumes execution after receiving the notification. 

FIGS. 6a-d show a representative process flow for the 
present invention based upon the sample script in FIG. 2. In FIG. 
6a, a user 602 at Location P launches a mobile script 302 from 
client machine 102a onto the communication network 108 which spans 
Locations P, Q, and R. The Agent Server 104a is disposed at 
Location Q. The Agent Server 104b and the Web Server 106 are 
disposed in Location R. After performing some computation, the 
mobile script 302 moves to location Q. 
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In FIG. 6b, the script executes the PRINT statement at 
location Q. As a result of execution, the output of the PRINT 
statement, "I am at machine Q", is added to the STDOUT buffer. 
Next, the script 302 executes the statement "READ A," Since the 
value of A is not available in the bag, the script 302 optionally 
sends notification to the user 602 and waits for a reply. The user 
notification can be implemented using technology such as a beeper, 
pager, e-mail, smart phone or handheld portable mobile device. 
After the user checks the status of the script 302 (as explained 
with reference to FIG. 5.), the user 602 supplies a value for 
variable A to the script 302. Additionally, under one optional 
optimization, the user also supplies a value for variable B to the 
script 302. Upon receiving these values, the script 302 resumes 
execution, immediately consuming the value for variable A. Since 
the value for variable B is not yet needed by the script 302, it is 
placed in the bag associated with the script 302 (see FIG. 6c). 
The script 302 then moves to the Agent Server 104b at Location R. 

In FIG. 6d, the script 302 generates the output "I am at 
machine R" as a result of executing the PRINT statement, at 
location R. The output is attached to the STDOUT buffer of script 
302. Next, the script 302 executes the statement "READ B". Since 
the value for variable B is already available in the bag, the 
program retrieves the value from the bag and completes execution, 
without the need for preparing and sending notification to the 
user. Clearly, more than one additional value can be input by the 
user and stored in the bag buffer for subsequent use by the 
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program. 

Now that; the Invention has been described by way of a 
preferred embodiment, various modifications and improvements will 
occur to those of skill in the art. Thus, it should be understood 
that the preferred embodiment is provided as an example and not as 
a limitation. For instance, along with the notification, the 
contents of the STDOUT buffer 306 can be transmitted to the user's 
device, assuming the device is capable of receiving such data 
(e.g., pager or smart phone). In addition, a user, using the 
systOTi of the present invention, can optionally communicate with a 
particular AES via e-mail. The scope of the invention is defined 
by the appended claims. 
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